Many applications and operating systems (especially in a multi-user environment) support security mechanisms which include some form of user authentication. Typically a user authenticates (that is, “logs on”) to the application or operating system. The application or operating system then creates a security context. A security context is a representation of the user's identity as well as any authorization information associated therewith. For example, the context may include the user's identifier (user ID), the user's role, and group membership. Once logged on, the information associated with the security context is used by the application or operating system to determine whether the user has the proper authority to access requested resources or take selected actions.
By way of example, consider a user accessing a “secure” website, using a web browser. The website requests logon information from the user, typically consisting of a user ID and a password. The user supplies values for both, and the web server verifies that the combination provided by the user is valid, and creates a security context for the user. An illustrative security context 100 is schematically depicted in FIG. 1. In this example, security context 100 has a user ID field 102 with the value “identitya,” a role field 104 containing the role of the user associated with identitya, here an Administrator denoted by the value “Admin,” and two group fields 106A and 106B indicating that the user associated with identitya is a member of two groups, denoted by the values TeamA, and Staff. The browser user, now logged on, and associated with identitya, attempts to retrieve information from the web server. Based on the information in the security context, the web server determines whether the users request can be satisfied. If, for example the requested information can be accessed by any user in TeamA, then the request can be satisfied.
An application or operating system may support a sequence of logons (which, particularly in directory server applications, may be referred to as binds) without requiring the user to log off before logging on again. Additionally, an individual user may be associated with different identities (that is, user ID values) wherein a unique context is associated with each identity. Thus, for example, a System Administrator may have an identity which associates a security context in the role of System Administrator, and a second identity that associates a context with the user that includes roles as System Administrator and Printer Administrator. The access authorities available to the same user in the security context associated with the different identities need not be the same.
The application or operating system may employ one of several alternatives when creating and destroying security context. In a first alternative, when the user logs on, and a security context is created, any pre-existing security context is destroyed. When the user logs off the security contest is destroyed. This alternative is typically used when logging into web and LDAP servers. (An artisan of ordinary skill in the art would understand that LDAP refers to the Lightweight Directory Access Protocol, which is an open industry standard for accessing a directory, which is a particular database containing information describing attributes associated with users and resources on a network. The specifications for the LDAP Version 3 may be found in Request for Comments (RFC) 2251. (RFCs are known by artisans of ordinary skill in the data processing art to be publications by which Internet standards are promulgated.) An alternative model saves a pre-existing security context by, for example, pushing the context onto a stack, and a new security context created. The new security context is used to access resources. When the user logs off, the new security context is destroyed, and the pre-existing security context is restored, that is, popped off the stack. This model is supported by, for example, the Distributed Computing Environment (DCE). (An artisan of ordinary skill in the art would recognize the DCE as a standardized architecture for distributing applications transparently across networks of computers. DCE is promulgated by the Open Software Foundation (OSF).) In both of these models, the user's access is determined by the current security context. Thus, if the user needs access that requires authority not associated with the current context, the user must log onto the system with the user's identity that corresponds to a security context that is associated with the required level of access authority. As a consequence, the security policies may typically be established in a simple hierarchical structure, whereby each level of authorization includes all of the access rights granted by the authorization levels lower in the hierarchy. This may be understood by referring to FIG. 1B illustrating a hierarchical structure of access authority in Venn diagram form. In the exemplary hierarchical structure in FIG. 1B, four levels of authority are depicted. Level 108 may be associated with general user access authority. Level 110 may be associated with Printer Administrator access authority, which access authority includes all of the general user authority and additionally, authority necessary to perform the tasks associated with maintaining and configuring networked printer resources. Level 112 may correspond to the authorization level for a Network Administrator. In the hierarchical structure of FIG. 1B, these authorities would include the authorities granted general users as well as those granted the Printer Administrator and additionally the authorities required to perform the tasks associated with the management of the network generally. Level 114 may be associated with a System Administrator, which authorities include those of the general user, the Printer and Network Administrators, and additionally the authorities necessary to perform the tasks associated with management of the overall system. Consequently, in such a structure, when say for example, the Network Administrator logs on to perform a general user operation, perhaps access to a distributed application, for example, a spreadsheet application, the Network Administrator is logged on with additional authorities not necessary to perform the current task. Such logons with authorities that are not necessary present opportunities for security breaches. Thus the hierarchical structure, of which FIG. 1B is exemplary, is not a particularly satisfactory alternative to the problem of multiple logons and logouts. Consequently, there is a need in the art for mechanisms to permit finer granularity in access authorization structures without exacerbating the complications associated with multiple user logins.